⬅️ Back to 10 🧠 Knowledge

Problem statements

The artifact Problem framing produces. Framing is the thinking; the statement is the thing you write down, circulate, and get agreement on.

What it is

a problem statement is used to identify and frame the problem to be explored and solved, and to communicate the discovery's scope and focus
a concise description of the problem that needs to be solved - a nice, snappy definition
some discoveries begin with investigating solutions, rather than the problems those solutions are intended to solve - if you don't know the problem, you're not going to have much luck solving it
the better a problem is articulated, the easier and more effectively it can be solved
they are also great communication tools - a well-written one gains buy-in from stakeholders on why it's important to explore and solve the problem
write one as early as possible in discovery, as it helps set discovery goals and objectives
it should be written in plain language - no professional jargon or acronyms; anyone reading it should easily understand what the problem is you're trying to solve
roughly corresponds to the epic
- epic title should not be vague but way more specific
- the problem describes the shift in customer behavior

What it should include

a problem statement should include:
1. The background of a problem. Which organization or department has the problem and what is the problem? Why has the problem arisen? (in some cases you may not know the exact causes - discovery can help with that)
2. The people affected by the problem. There could be multiple user groups affected in different ways - call out how the problem affects users.
3. The impact of the problem on the organization. If it is not fixed, what will be the effect? Reputational damage? Unavoidable costs? Losing market share?
an alternative three-part shape that works well:
1. background and context - what was meant to happen? What was the existing service or product meant to do? What is the context (where is it happening, online or offline)? Who are the users?
2. what is the problem? - what is happening now? How do you know a problem exists? What can you observe? What can you see in the data? This is where facts from research or data analysis belong
3. what is the effect of that? - what is happening because of the problem? What does the data tell you? This section tells you which metrics you can use to see if your solution works
example: Users of our newspaper app often export content from our app, rather than sharing content through our app. This is a problem because target audiences are less likely to know that the content came from our app, leading to lower conversion rates. This is also a problem for app users, as exporting content is time-consuming and could lead to a decrease in app usage.
if you don't have all the answers, don't panic - while you should know what the problem is, you may not know exactly why it came about; that is what discovery should tackle

Gathering the facts: the 5 Ws

A simple technique for gathering the relevant facts before writing the statement.

What
- What is the focus of the problem?
- What is the problem?
- What supporting evidence is there about this problem?
Who
- Who is affected by the problem?
- How do we know?
- How are their voices present in the problem statement?
Where
- Where does this problem occur?
- How does the context of the problem impact its expression?
When
- When does the problem occur - and what is the timeframe in which it has developed?
Why
- Why does the problem occur?
- Why is this problem worth addressing?
- What impact will addressing it have?

Opportunity statements

problem statements can also capture opportunities (then sometimes called opportunity statements, though written and used the same way)
- example: The process of purchasing a newly built home can take a long time and requires many offline activities. This means sales often take a long time to close. There's an opportunity to make home buying quicker and easier, and thus improve customer-satisfaction ratings and sales.

User need statements

a fundamental tool for defining and aligning on the problem you are going to solve, used before spending time and resources generating possible solutions
this maximizes resource use and decreases the likelihood of friction and disagreement in the prototyping, testing and implementation stages
the purpose of user need / problem statements is to capture what we want to achieve with our design, not how
they encourage us to see users' needs as verbs (goals and end states) instead of nouns that describe solutions
- for example, users don't ever need a dropdown (noun); they need to see the choices they can make and select one of them (verb)
- the nouns are possible solutions to users' needs, but not the only ones - focusing on them risks suboptimal designs
traditional need statements have 3 components: 1) a user, 2) a need, 3) a goal, combined as [A user] needs [need] in order to accomplish [goal]
- for example, [Alieda, a multitasking, tech-savvy mother of 2] needs [to quickly and confidently compare options without leaving her comfort zone] in order to [spend more time doing the things that really matter]
keep in mind: users do not always know what they need, even though they may say so
the insight, or goal, is the result of meeting that need - it should be rooted in empathy (see Insight)